1. Field of the Invention
The invention relates to a technique including both apparatus and an accompanying method, for forming and embedding a hidden highly tamper-resistant cryptographic identifier, i.e., a watermark, within non-marked computer executable code, e.g., an application program, to generate a “watermarked” version of that code. This technique can also be used to tightly integrate, in a highly tamper-resistant manner, other pre-defined executable code, such as security code, as part of the watermark, into the non-marked code in order to form the watermarked code.
2. Description of the Prior Art
Over the past decade or so, personal computers (PCs) have become rather ubiquitous with PC hardware and software sales experiencing significant growth. However, coincident with an ever widening market for PCs, unauthorized copying of PC software, whether it be application programs or operating systems, continues to expand to rather significant proportions. Given that in certain countries sales lost to such copying can significantly exceed legitimate sales, over the years software manufacturers have attempted to drastically reduce the incidence of unauthorized copying though, practically speaking, with only limited success.
One such technique, probably one of the oldest techniques used and usually rather ineffective, is simply to append a copyright and other legal proprietary rights notices to object code as distributed on mass (magnetic or optical) media. The intention in doing so is to deter unauthorized copying by simply placing a third party on notice that a copy of the program, embodied by that code, is legally protected and that its owner may take legal action to enforce its rights in the program against that party to prevent such copying. These notices can be readily discovered in program code listings and simply excised by the third party prior to copying and distributing illicit copies. Other such notices can be excised by a third party adversary from the software media itself and the program packaging as well. Though these notices are often necessary in many jurisdictions to secure full legal remedies against third parties, in practice, these notices have provided little, if any, real protection against third party copying.
Another technique that is recently seeing increasing use is to require a PC, on which the program is to execute, to hold a valid digital “certificate” provided by the manufacturer of the program. The certificate will typically be loaded as a separate step during manufacture of the PC. During initialization, the program will test the certificate and confirm its authenticity and validity. If the certificate is authentic and valid, the program will continue to execute; otherwise, the program will simply terminate. Unfortunately, the certificate and associated testing routines are often very loosely bound to the remainder of the program code. Currently available software analysis tools can display execution flow among program instructions in a program under test. Consequently, with such tools, a programmer, with knowledge of an operational sequence implemented by the program and by analyzing a flow pattern inherent in that program, as it executes, can readily discern the program code that implements a certificate testing function. Once this code is detected, the programmer can readily excise that portion from the program itself and simply modify the remaining program code, by, e.g., by inclusion of appropriate jump instruction(s), to compensate for the excised portion; thus, totally frustrating the protection which the certificate was intended to provide against unauthorized copying. Once having done so, a third party adversary can then produce and distribute unauthorized, but fully executable, copies of the program free of all such protection. Thus, in practice, this approach has proven to be easily compromised and hence afforded very little, if any, real protection against illicit copying.
Other techniques have relied on using serialized hardware or other hardware centric arrangements to limit access to a program to one or more users at one particular PC and preclude that program from being loaded onto another PC. Generally, these techniques, often referred to as “copy protect” schemes and which were popular several years ago, relied on inserting a writeable program distribution diskette, such as a floppy diskette, into a PC and then, during execution of an installation process from that diskette, have that PC store machine specific data, such as a hardware identification code, onto the diskette. Thereafter, during each subsequent installation of the program, an installation process would check the stored machine specific data on the installation diskette against that for a specific PC on which the program was then being installed. If the two pieces of data matched, installation would proceed; otherwise, it would prematurely terminate. Unfortunately, such schemes, while generally effective against unauthorized copying, often precluded legitimate archival copying as well as a legitimate installation of the program on a different PC. In view of substantial inconveniences imposed on the user community, such “copy protect” schemes quickly fell into disuse and hence where basically abandoned shortly after they first saw widespread use. Moreover, any such technique that relies on storing information on the distribution media itself during program installation is no longer practical when today software is distributed on massive read-only optical media, such as CDROM or, soon, digital video disk (DVD).
Therefore, given the drawbacks associated with copy protect and certificate based schemes, one would think that embedding an identifier of some sort into a program, during its manufacture and/or installation and subsequently testing for that identifier during subsequent execution of an installed version of that program at a user PC, would hold promise.
However, for such an identifier based approach to be feasible, a need exists in the art for an identifier, such as a watermark, that can be tightly integrated into a program itself such that the watermark would be extremely difficult, if not effectively impossible, for a third party to discern, such as through flow analysis, and then circumvent, such as by removal.
In particular, such a watermark could be embedded in some fashion into a non-marked program. Then, subsequently, at runtime of an installed version of that program at a user PC, a “secret” key(s) based cryptographic process could be used to reveal the presence of and test the watermark. The key(s) would be separately stored down, to the PC, as a software value(s). If the correct watermark were then detected, execution of the installed program would continue; else, execution would halt. Fortunately, such an approach would likely impose essentially no burden on, and preferably be totally transparent to, the user, and not frustrate legitimate copying.
If such an identifier could be made sufficiently impervious to third party detection and tampering, then advantageously its use, with, for example, such an approach, may well prove effective, in practice, at reducing unauthorized third party copying.